Multi-protocol I/O interconnect including a switching fabric

ABSTRACT

Described are embodiments of methods, apparatuses, and systems for multi-protocol tunneling across a multi-protocol I/O interconnect of computer apparatus. A multi-protocol I/O interconnect may include a switching fabric operatively coupled to a first protocol-specific controller and a second protocol-specific controller, and may be configured to simultaneously route packets of the first protocol to the first protocol-specific controller and packets of the second protocol to the second protocol-specific controller. Other embodiments may be described and claimed.

PRIORITY

This application is a Continuation of, and claims the benefit ofpriority of, U.S. patent application Ser. No. 13/338,220, filed Dec. 27,2011.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to multi-protocoltunneling across a multi-protocol I/O interconnect of a computerapparatus.

BACKGROUND

Conventional computer platform architectures include a variety of hostcontrollers to implement a number of different types of I/O betweencomputer platforms and peripheral devices that are connected to theplatforms, and these computer platforms generally includeprotocol-specific connection interfaces that connect to the peripheraldevices via protocol-specific plugs and cables. For example, a computermay include one or more of a USB-specific controller that connects to aperipheral device via a USB-specific connection interface, adisplay-specific controller (e.g., DisplayPort) that connects to aperipheral device via a display-specific connection interface, a PCIExpress®-controller that connects to a peripheral device via a PCIExpress®-specific connection interface, and so on.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present disclosure will be described by way ofexample embodiments, but not limitations, illustrated in theaccompanying drawings in which like references denote similar elements,and in which:

FIG. 1 describes a computer apparatus including a multi-protocoltunneling I/O interconnect, in accordance with various embodiments ofthe present disclosure.

FIG. 2 describes a computer system including a multi-protocol tunnelingI/O interconnect, in accordance with various embodiments of the presentdisclosure.

FIG. 3 describes a switching fabric of a multi-protocol tunneling I/Ointerconnect, in accordance with various embodiments of the presentdisclosure.

FIG. 4 describes a protocol stack for a multi-protocol interconnectarchitecture of an I/O complex, in accordance with various embodimentsof the present disclosure.

FIG. 5 describes an implementation of a protocol stack for amulti-protocol interconnect architecture of an I/O complex, inaccordance with various embodiments of the present disclosure.

FIG. 6A describes a physical topology of a domain of switches, and FIG.6B describes a spanning tree for managing the domain of FIG. 6A, inaccordance with various embodiments of the present disclosure.

FIG. 7 describes a spanning tree in a domain, in accordance with variousembodiments of the present disclosure.

FIG. 8 describes a format of a route string for routing configurationpackets in a domain, in accordance with various embodiments of thepresent disclosure.

FIG. 9 describes a format of a topology ID configuration register, inaccordance with various embodiments of the present disclosure.

FIG. 10 describes connections that may be established between multipledomains, in accordance with various embodiments of the presentdisclosure.

FIG. 11 describes a multi-protocol tunneling I/O complex andinterconnect, in accordance with various embodiments of the presentdisclosure.

FIG. 12 describes a multi-protocol tunneling I/O complex andinterconnect, in accordance with various embodiments of the presentdisclosure.

FIG. 13 describes a device (e.g., a peripheral device) including amulti-protocol tunneling I/O interconnect connected with amulti-protocol tunneling I/O interconnect, both in accordance withvarious embodiments of the present disclosure.

FIG. 14 is a flow diagram of a method for configuring a multi-protocoltunneling I/O interconnect, in accordance with various embodiments ofthe present disclosure.

FIG. 15 is a flow diagram of a method for operating a computer apparatusincluding a multi-protocol tunneling I/O interconnect, in accordancewith various embodiments of the present disclosure.

FIG. 16 describes an article of manufacture having programminginstructions configured to cause an apparatus to practice some or allaspects of multi-protocol tunneling (of the methods of FIG. 15 and FIG.16, for example), in accordance with embodiments of the presentdisclosure.

DETAILED DESCRIPTION

Various aspects of the illustrative embodiments will be described usingterms commonly employed by those skilled in the art to convey thesubstance of their work to others skilled in the art. However, it willbe apparent to those skilled in the art that alternate embodiments maybe practiced with only some of the described aspects. For purposes ofexplanation, specific numbers, materials, and configurations are setforth in order to provide a thorough understanding of the illustrativeembodiments. However, it will be apparent to one skilled in the art thatalternate embodiments may be practiced without the specific details. Inother instances, well-known features are omitted or simplified in ordernot to obscure the illustrative embodiments.

Further, various operations will be described as multiple discreteoperations, in turn, in a manner that is most helpful in understandingthe illustrative embodiments; however, the order of description shouldnot be construed as to imply that these operations are necessarily orderdependent. In particular, these operations need not be performed in theorder of presentation. Moreover, methods within the scope of thisdisclosure may include more or fewer steps than those described.

The phrase “in some embodiments” is used repeatedly. The phrasegenerally does not refer to the same embodiments; however, it may. Theterms “comprising,” “having,” and “including” are synonymous, unless thecontext dictates otherwise. The phrase “A and/or B” means (A), (B), or(A and B). The phrase “A/B” means (A), (B), or (A and B), similar to thephrase “A and/or B”. The phrase “at least one of A, B and C” means (A),(B), (C), (A and B), (A and C), (B and C) or (A, B and C). The phrase“(A) B” means (B) or (A and B), that is, A is optional.

FIG. 1 describes a computer apparatus 100 including a multi-protocoltunneling I/O interconnect 108 in accordance with various embodiments.In many embodiments, the computer apparatus 100 may include one or moreprocessors 102. In different embodiments, the one or more processors 102may include one core or multiple cores. In some embodiments, theapparatus 100 may be a multiprocessor system (not shown) where each ofthe processors has one core or multiple cores.

As shown in FIG. 1, the one or more processors 102 may be operativelycoupled to system memory 104 through one or more links (e.g.,interconnects, buses, etc). System memory 104 may be capable of storinginformation that the one or more processors 100 utilize to operate andexecute programs and operating systems. In different embodiments, systemmemory 104 may be any usable type of readable and writeable memory suchas a form of dynamic random access memory (DRAM).

In previously implemented computer apparatuses, an I/O link connecting aperipheral device to a computer system is protocol-specific with aprotocol-specific connector port that allows a compatible peripheraldevice to be attached to the protocol-specific connector port (i.e., aUSB keyboard device would be plugged into a USB port, a router devicewould be plugged into a LAN/Ethernet port, etc.) with aprotocol-specific cable. Any single connector port would be limited toperipheral devices with a compatible plug and compatible protocol. Oncea compatible peripheral device is plugged into the connector port, acommunication link would be established between the peripheral deviceand a protocol-specific controller.

In the computer apparatus as described in the embodiment shown in FIG.1, the one or more processors 102 may be operatively coupled to an I/Ocomplex 106, which may house one or more multi-protocol I/Ointerconnects 108 configured to control one or more I/O links that allowthe one or more processors 102 to communicate with one or more I/Operipheral devices 110. For providing the multi-protocol capability, atleast in part, the I/O interconnect 108 may include a multi-protocolswitching fabric 114 configured to carry multiple I/O protocols. Invarious embodiments, the multi-protocol switching fabric 114 maycomprise a plurality of cross-bar switches. Examples of I/O peripheraldevices 110 may include a display device, a keyboard device, anexpansion port, a desktop or mobile computer system, or a router, amongother devices.

A non-protocol-specific connector port 112 may be configured to couplethe I/O interconnect 108 with a connector port (not shown) of the device110, allowing multiple device types to attach to the computer system 100through a single physical connector port 112. Moreover, the I/O linkbetween the device 110 and the I/O complex 106 may be configured tocarry multiple I/O protocols (e.g., PCI Express®, USB, DisplayPort,HDMI®, etc.) simultaneously. In various embodiments, the connector port112 may be capable of providing the full bandwidth of the link in bothdirections with no sharing of bandwidth between ports or betweenupstream and downstream directions. In various embodiments, theconnection between the I/O interconnect 108 and the device 110 maysupport electrical connections, optical connections, or both.

The apparatus 100 may be a stand-alone device or may be incorporatedinto various systems including, but not limited to, various computingand/or consumer electronic devices/appliances, such as desktop computingdevice, a mobile computing device (e.g., a laptop computing device, ahandheld computing device, a tablet, a netbook, etc.), mobile phones,smart phones, personal digital assistants, servers, workstations,set-top boxes, digital reorders, game consoles, digital media players,and digital cameras. A block diagram of an example system 200 isillustrated in FIG. 2. The system 200 may comprise one or moreprocessor(s) 202, system memory 204, and an I/O complex 206, alloperatively coupled by a bus 115. The I/O complex 206 may include one ormore multi-protocol I/O interconnects 208, each of which include aswitching fabric 214 and control one or more I/O links that allow theone or more processors 202 to communicate with one or more I/Operipheral devices 210. In various embodiments, the system 200 may havemore or fewer components, and/or different architectures.

The system 200 may include communications interface(s) 217 operativelycoupled to the bus 215 to provide an interface for system 200 tocommunicate over one or more networks and/or with any other suitabledevice. The communications interface(s) 217 may include any suitablehardware and/or firmware. The communications interface(s) 217 for oneembodiment may include, for example, a network adapter, a wirelessnetwork adapter, a telephone modem, and/or a wireless modem. Forwireless communications, the communications interface(s) 217 for oneembodiment may include a wireless network interface controller 219having one or more antennae 221 to establish and maintain a wirelesscommunication link with one or more components of a wireless network.The system 200 may wirelessly communicate with the one or morecomponents of the wireless network in accordance with any of one or morewireless network standards and/or protocols.

The system 100 may include a display device 223, such as, for example, acathode ray tube (CRT), liquid crystal display (LCD), light emittingdiode (LED), or other suitable display device, operatively coupled tothe bus 215 for displaying information. In various embodiments, thedisplay device 223 may be a peripheral device interconnected with thesystem 200. In various ones of these embodiments, such a peripheraldisplay device may be interconnected with the I/O complex 206 by way ofthe multi-protocol port 212.

As described herein, for providing an I/O interconnect capable ofcarrying multiple I/O protocols, one or more of the various I/Ointerconnects described herein may include, among other things, amulti-protocol switching fabric 314 comprising a plurality of cross-barswitches, as shown in FIG. 3. The multi-protocol switching fabric 314may be similar to other multi-protocol switching fabrics describedherein. In general, the switches 316 a, 316 b are devices comprisingmultiple ports 320 s, 320 b, 322 a with the ability to route a packetfrom any input port to any output port. In various embodiments, theswitches 316 a, 316 b may comprise any number of ports 320 s, 320 b, 322a, with each additionally including an internal control port 326 a, 326b. The switches 316 a, 316 b may each optionally include a timemanagement unit 330 a, 330 b for use in distributing and synchronizingtime throughout the multi-protocol switching fabric 314, as describedmore fully herein.

Switch 316 a may represent a first type of switch including null ports320 a configured to connect to a single optical or electrical link,while adapter ports 322 a may be configured to connect to one or moremapped I/O protocol links. The adapter ports 322 a may be used toconnect mapped I/O protocol entities to the multi-protocol switchingfabric 314. As used herein, the term “adapter” may be used to refer tothe protocol adaptation function that may be built into the switch portto encapsulate the mapped I/O protocol packets into I/O packets thatflow over the multi-protocol switching fabric 314.

Switch 316 b may represent a second type of switch including only nullports 320 b (like null ports 320 a) configured to connect to a singleoptical or electrical link.

Although the switches 316 a, 316 b depicted in FIG. 3 each include fouradapter ports 322 a and four null ports 320 a, 320 b, the actual numberof ports 320 a, 320 b, 322 a may be fewer or more than that shown. Inorder to provide connectivity between switches 316 a, 316 b, a switchimplementation generally minimally includes either at least one nullport and at least one adapter port, or at least two null ports.

In various embodiments, the multi-protocol switching fabric 314 maycomprise one or more of the first type of switches 316 a and one or moreof the second type of switches 316 b.

For implementing various multi-protocol tunneling between adapter portsof a switching fabric within the scope of the present disclosure, aconnection manager (not illustrated) may be provided. The connectionmanager may be implemented in software, firmware, as logic within an I/Ocomplex, as part of a system BIOS, or within an operating system runningon a computer apparatus or system in which the I/O complex is included.

An example protocol stack for the multi-protocol interconnectarchitecture of an I/O complex is shown in FIG. 4. The electrical andoptical sublayers, the logical sublayer, the transport layer, and theframe layer may define the base multi-protocol interconnect architectureof the I/O complex, in which the physical layer comprises theelectrical, optical, and logical sublayers. The mapped protocol layersmay describe the mapping of the specific I/O protocols onto themulti-protocol interconnect architecture.

In various embodiments, and with reference to FIG. 3 and FIG. 4, thetransport layer may be implemented by all ports 320 a, 320 b, 322 a ofthe switches 316 a, 316 b of the multi-protocol switching fabric 314,the physical layer may be implemented by all null ports 320 a, 320 b,and the adapter ports 322 a may implement a single mapped protocol layeror the frame layer.

An example implementation of the protocol layering is shown in FIG. 5.In the example shown, two protocols are implemented using switches 516a, 516 b, 516 c, 516 d. Each of the switches 516 a, 516 b, 516 c, 516 dinclude control ports 526 a, 526 b, 526 c, 526 d, and time managementunits 530 a, 530 b, 530 c, 530 d.

As shown, the adapter ports 522 a 1, 522 c implement a first protocollayer (or frame layer) “protocol 1,” and adapter ports 522 a 2, 522 dimplement a second protocol layer (or frame layer) “protocol 2.” Allports implement the transport layer, while the physical layer isimplemented by all null ports 520 a, 520 b, 520 c, 520 d.

As such, a link (e.g., link 532) between ports of switches mayeffectively be shared by multiple paths traversing the fabric betweenadapter ports of the multi-protocol switching fabric. In variousembodiments, the multi-protocol interconnect architecture may beconnection-oriented such that a path is configured end-to-end beforedata transfer takes place. The path may traverse one or more linksthrough the multi-protocol switching fabric, and each hop, the path maybe assigned a locally unique identifier that may be carried in theheader of all the packets that are associated with the path. In variousembodiments, packets belonging to the path may not be reordered withinthe multi-protocol switching fabric. Buffer allocation (flow control)and Quality of Service may be implemented on a per-path basis. As such,a path may provide virtual-wire semantics for a mapped I/O protocolacross the multi-protocol switching fabric.

In various embodiments, the physical topology of a collection ofswitches (a domain) may be an arbitrarily interconnected graph. FIG. 6Ashows an example of a physical topology of a domain of switches 1-6. Itshould be noted that a domain is a management concept rather than anoperational one. In various embodiments, a connection manager, asdescribed earlier, may configure the domains of a switching fabric. Forfurther management purposes, a multi-protocol apparatus may beconfigured to create a spanning tree (by way of the connection manager,for example). FIG. 6B shows an example spanning tree created formanaging the domain of FIG. 6A in which the switch 1 at the top of thespanning tree may be referred to as the root switch. It is noted that aspanning tree may include any suitable number of levels. In variousembodiments, the maximum number of levels of the spanning tree may beseven.

FIG. 7 shows an example of a spanning tree in a domain. Also shown areexample assignments of unique topology IDs to each of the switches inthe domain. For example, switch J has a topology ID of 0,4,1,1,2,1,8. Invarious embodiments, unique topology IDs may be assigned to every switchof a domain and each topology ID may represent the position of theswitch within the spanning tree of the domain. In various embodiments,the assignment of the topology IDs may be done by the connection managerduring initialization in which the domains may be created by enumeratingthe switches that are reachable and the topology IDs may be assigned foreach switch.

As shown in FIG. 7, the domain includes seven levels (levels 0-6), andthe topology IDs of each of the switches are sequences of seven portnumbers representing the egress ports at each level of the tree on thepath, from the root switch to itself. The topology ID of a switch at adepth of X (where X is from 0 to 6 in this example) may contain anon-zero port number for levels 0 to X−1. The port number at depth X maybe 0 denoting the control port of the switch at depth X. The portnumbers from depth X+1 to 6 may be treated as “don't care” and may beset at 0. Thus, in the example shown, the control port at the rootswitch has a topology ID of 0,0,0,0,0,0.

In various embodiments, the routing of configuration packets flowingdownstream (in relation to the spanning tree) may be based on thetopology ID of the target switch. The configuration packets may berouted in the transport layer packet header. In various embodiments,configuration packets flowing upstream may not use the topology ID andmay simply be forwarded over the upstream port of each switch.Typically, every configuration packet carries a route string included inits payload. An example format of the route string is shown in FIG. 8.As shown, the route string may essentially be the topology ID of theswitch to which the configuration request is sent or from which theconfiguration response originates. The MSB bit (CM bit) of the routestring may be set to 0 when the configuration message is flowingdownstream (from the connection manager to the switch) and set to 1 ifthe message is flowing in the upstream direction.

In various embodiments, each switch may be configured with its topologyID and its level in the spanning tree by the connection manager. Eachswitch may also be configured with the port number that points upstreamto the connection manager of the domain either through hardwarestrapping or other similar mechanisms. In various embodiments, thetopology ID, depth (in the tree), and upstream facing port may beconfiguration registers in the switch configuration space of everyswitch that are initialized by the connection manager duringenumeration. An example format of the topology ID configuration registeris shown in FIG. 9. For the illustrated example, the MSB of the topologyID may be a valid flag, which may be set to 0 on reset and set to 1 bythe connection manager when the topology ID is initialized. The reservedbits of the topology ID may be set to 0.

Configuration packets flowing down the tree may be routed by the controlport of a switch in accordance with one or more rules. For example, invarious embodiments, the control port of the switch may be required toextract the port from the route string that corresponds to itsconfigured level in the tree. In various embodiments, if the port is 0,the control port may be required to consume the packet. In variousembodiments, if the port is non-zero, the control port may be requiredto forward the packet over the switch port that matches the portextracted from the route string. In various embodiments, configurationpackets flowing up the spanning tree may simply be forwarded over theconfigured upstream facing port.

Multiple domains may interconnected in various embodiments. FIG. 10shows example connections that may be established between multipledomains. As shown, switches 1-6 of Domain 1 may be interconnected withswitches A-E of Domain 2.

In various embodiments, inter-domain links may be discovered either whenthe connection manager performs the initial discovery of the topologyfollowing power-on or by processing a hot-plug event. A link may bedesignated to be an inter-domain link when a read of the switchconfiguration space of the switch across the link results in an ERRORpacket being sent that shows that the topology ID field has beenpreviously assigned. When an inter-domain link is discovered, theconnection manager may notify system software. The mechanism used todeliver the notification may be implementation-defined.

In various embodiments, the transport layer may only define the routingof inter-domain configuration packets between the two connectionmanagers of the domains that are connected by an inter-domain link.Routing of configuration packets across multiple domains may becontrolled by system software. When domains are daisy-chained,configuration packets passing from the originating domain may bedelivered to the connection managers of every domain along the path tothe target domain. The connection managers of the intermediate domainsmay pass the configuration packets to the system software which may beresponsible for relaying the packet across the inter-domain link towardsthe target domain.

The routing of inter-domain REQUEST packets may be in accordance withone or more rules. For example, in various embodiments, system softwareon the originating domain may form REQUEST packet with a route stringthat points to the egress port of the domain that connects to theinter-domain link over which the packet must be forwarded and the CM bitmay be set to 0. The packet may be required to be routed based on theroute string at each hop within the domain and forwarded over the egressport across the inter-domain link. At the ingress port of the receivingdomain, the control port may remap the route string to point to theingress port over which the packet was received and the CM bit may beset to 1. In various embodiments, the packet may then be required to berouted to the connection manager of the receiving domain like otherintra-domain configuration packets. The packet may be required to bedelivered by the connection manager of the receiving domain to systemsoftware.

The routing of inter-domain RESPONSE packets may follow one or more ofthe same steps above. In various embodiments, system software thatconstructs the RESPONSE packet may use the route string in thecorresponding REQUEST packet with the CM bit set to 0.

In various embodiments, the transport layer may employ a hierarchical,credit-based flow control scheme with respect to flow through themulti-protocol switching fabric to prevent or minimize overflow ofreceive buffers due to congestion. In various embodiments, the flowcontrol scheme may allow a receiver to implement various bufferallocation strategies ranging from dedicated buffers per-path to sharedbuffer pools that are dynamically shared by multiple paths. In variousembodiments, flow control may be turned off on a per-path basis. Whenflow control is turned off for a path, the path may be required to beprovisioned with a receive buffer that can hold at least one maximumsized transport layer packet at each link.

FIG. 11 shows an example I/O complex 1106 in accordance with variousembodiments. I/O complex 1106 may be similar to the I/O complex 106 ofFIG. 1, including an I/O interconnect 1108 configured to couple with adevice 1110. The device 1110 may be configured with one or more I/Oprotocols (e.g., PCI Express®, USB, DisplayPort, HDMI®, etc.).

In various embodiments, the I/O complex 1106 may be configured toconnect the device 1110 with one or more protocol-specific controllers1109 a, 1109 b . . . 1109 n via the I/O interconnect 1108 in order totunnel multiple I/O protocols over a common link in a manner that istransparent to the OS software stacks of tunneled I/O protocols. Theprotocol-specific controllers 1109 a, 1109 b, . . . 1109 n may beconfigured to then communicate with respective protocol-specific driversin the OS for configuring the device 1110 as if the device 1110 wasdirectly connected with the protocol-specific controller 1109 a, 1109 b,. . . 1109 n.

FIG. 12 shows an example hardware and software implementation of amulti-protocol apparatus (such as apparatus 100 of FIG. 1, for example)configured to tunnel multiple I/O protocols over a common link in amanner that is transparent to operating system software stacks oftunneled I/O protocols. In various embodiments, a multi-protocolapparatus may employ a multi-level hot-plug signaling scheme to supportthe tunneling of multiple I/O protocols over a common interconnect in asoftware-transparent manner.

For the implementation shown in FIG. 12, an I/O hot-plug indication maybe sent by the I/O interconnect 1208 to the I/O driver in the OS (or toembedded I/O firmware) when the device 1210 is plugged into thenon-protocol-specific connector port 1212 of the apparatus 1200. Thehot-plug indication may then be processed by the I/O driver 1213 in theOS/firmware, resulting in communication path(s) being establishedbetween the I/O interconnect 1208 and the device 1210. In variousembodiments, establishing communication path(s) may include configuringone or more paths between a source adapter and a destination adapter ina domain (described more fully elsewhere). Once the path(s) areestablished, mapped I/O protocol-specific configuration may be performedin which a protocol-specific hot-plug indication may be sent by theassociated protocol-specific controller 1209 a, 1209 b, . . . 1209 n tothe respective protocol-specific driver 1211 a, 1211 b, . . . 1211 n inthe OS/firmware. The protocol-specific driver 1211 a, 1211 b, . . . 1211n may then configure the associated protocol-specific controller 1209 a,1209 b, . . . 1209 n as if the device 1210 was directly connected withthe protocol-specific controller 1209 a, 1209 b, . . . 1209 n. At thispoint, the peripheral device 1210 may be visible to system software andconfigured to be used by applications.

In various embodiments, the apparatus 1200 may be configured such thatwhen the device 1210 is disconnected from the port 1212, a reversesequence of events may occur. Specifically, the protocol-specificdrivers 1211 a, 1211 b, . . . 1211 n may process the protocol-specificunplug event, and then after the protocol-specific processing, the I/Odriver 1213 may process the I/O unplug event.

Peripheral devices described herein (device 110, 210, 1110, or 1210, forexample) may be any one of various types of devices, as noted earlier.In various embodiments, the peripheral device may be an expansion port(or other multi-protocol peripheral device) with which one or more otherdevices, with one or more I/O protocols, may be coupled. For example,for embodiments in which the peripheral device is an expansion port, thedevice may be simultaneously coupled with a PCI Express® device and aDisplayPort device, which may be coupled with an I/O complex through theexpansion port device. In another example, the peripheral device may bea mobile or desktop computer system and one or more other devices may becoupled with the mobile or desktop computer system and with the I/Ocomplex through the device. In various embodiments, multiple peripheraldevices may be coupled together by daisy chaining the devices together.

In various embodiments, the peripheral device and/or the other devicescoupled with the peripheral device may also include an I/O interconnectsimilar to one or more of the I/O interconnects 108, 208, 1108, 1208described herein. As shown in FIG. 13, for example, a device 1310including a multi-protocol interconnect 1301, which in turn includes amulti-protocol switching fabric 1303, may be configured to beinterconnected with a multi-protocol apparatus 1300 which also includesa multi-protocol interconnect 1308 and switching fabric 1314. One ormore other peripheral devices 1305 a, 1305 b, . . . 1305 n may beinterconnected with the I/O interconnect 1301 via one or morecorresponding non-protocol-specific ports 1312.

FIG. 14 is a flow diagram of an example method 1400 for configuring amulti-protocol tunneling I/O interconnect, in accordance with variousembodiments of the present disclosure. The method 1400 may include oneor more functions, operations, or actions as is illustrated by blocks1402-1410.

Processing for the method 1400 may start with block 1402 by identifyinga plurality of switches of a switching fabric of a multi-protocolinterconnect.

The method 1400 may proceed to block 1404 by creating a spanning treerepresentation of the plurality of switches.

The method 1400 may proceed to block 1406 by assigning uniqueidentifications (IDs) to the switches of plurality of switches of thespanning tree. In various embodiments, the IDs may represent therelative positions of the switches within the spanning tree.

The method 1400 may proceed to block 1408 by storing the IDs and depthof the switches (in the spanning tree) in one or more registers of eachof the switches.

The method 1400 may proceed to block 1410 by routing configurationpackets through the spanning tree to the switches based at least in parton their respective IDs.

FIG. 15 illustrates an example method for operating a computer apparatusincluding a multi-protocol tunneling I/O interconnect, in accordancewith various embodiments of the present disclosure. The method 1500 mayinclude one or more functions, operations, or actions as is illustratedby blocks 1502-1522.

Processing for the method 1500 may start with block 1502 by determiningwhether a peripheral device has been plugged into anon-protocol-specific port of a computer apparatus including amulti-protocol tunneling I/O interconnect. Plugging may refer to aperipheral device being directly coupled with the non-protocol-specificport and/or a target peripheral device being directly coupled to someother peripheral device directly coupled with the non-protocol-specificport. In the latter embodiments, one or more other peripheral devicesmay be operatively disposed between the target peripheral device and thenon-protocol-specific port. If no peripheral device has been plugged,then processing in block 1502 may repeat. In various embodiments, thecomputer apparatus may be configured to issue an interrupt signalindicating when a peripheral device has been plugged (e.g.,hot-plugged).

Processing for the method 1500 may proceed to block 1504 by determiningwhether a data packet has been received. If no data packet has beenreceived, then processing in block 1504 may repeat. In variousembodiments, a data packet may be received from the peripheral device orfrom within the computer apparatus. In various embodiments, data packetswithin the computer apparatus may be received by the multi-protocoltunneling I/O interconnect from a protocol-specific controller (“hostprotocol-specific controller”) of the computer apparatus.

Processing for the method 1500 may proceed to block 1506 by determiningwhether the data packet was received from the peripheral device or froma host protocol-specific controller. If no data packet has beenreceived, then processing in block 1506 may repeat.

If the data packet was received from the peripheral device, processingfor the method 1500 may proceed to block 1508 by encapsulating packetsof a first protocol into first transport layer packets configured to berouted through the switching fabric of the I/O interconnect. In variousembodiments, packets of a second protocol, different from the firstprotocol, may also be encapsulated into second transport layer packetsfor routing through the switching fabric.

Processing for the method 1500 may proceed to block 1510 bysimultaneously routing the first and second transport layer packetsthrough the switching fabric of the I/O interconnect.

Processing for the method 1500 may proceed to block 1512 bydecapsulating the transport layer packets. In various embodiments,decapsulation may be performed an adapter port of a switch of theswitching fabric.

Processing for the method 1500 may proceed to block 1514 by routing thedecapsulated packets to different host protocol-specific controllers ofthe computer apparatus.

If the data packet was received from the peripheral device, processingfor the method 1500 may proceed from block 1506 to block 1516 byencapsulating packets of a first protocol into first transport layerpackets configured to be routed through the switching fabric of the I/Ointerconnect. In various embodiments, packets of a second protocol,different from the first protocol, may also be encapsulated into secondtransport layer packets for routing through the switching fabric.

Processing for the method 1500 may proceed to block 1518 bysimultaneously routing the first and second transport layer packetsthrough the switching fabric of the I/O interconnect.

Processing for the method 1500 may proceed to block 1520 bydecapsulating the transport layer packets. In various embodiments,decapsulation may be performed an adapter port of a switch of theswitching fabric.

Processing for the method 1500 may proceed to block 1522 by routing thedecapsulated packets to a peripheral device via a non-protocol-specificport of the computer apparatus.

In various embodiments, an article of manufacture may be employed toimplement one or more methods as disclosed herein. FIG. 16 describes anexample article of manufacture 1600. As shown, the article ofmanufacture 1600 may include a computer-readable non-transitory storagemedium 1602 and a storage medium 1602. The storage medium 1602 mayinclude programming instructions 1604 configured to cause an apparatusto practice some or all aspects of multi-protocol tunneling, inaccordance with embodiments of the present disclosure.

The storage medium 1602 may represent a broad range of persistentstorage medium known in the art, including but not limited to flashmemory, optical disks or magnetic disks. The programming instructions1604, in particular, may enable an apparatus, in response to theirexecution by the apparatus, to perform various operations describedherein. For example, the storage medium 1602 may include programminginstructions 1604 configured to cause an apparatus to practice some orall aspects of multi-protocol tunneling of the methods of FIG. 14 andFIG. 15, for example, in accordance with embodiments of the presentdisclosure.

Although various example methods, apparatus, systems, and articles ofmanufacture have been described herein, the scope of coverage of thepresent disclosure is not limited thereto. On the contrary, the presentdisclosure covers all methods, apparatus, and articles of manufacturefairly falling within the scope of the appended claims either literallyor under the doctrine of equivalents. For example, although the abovediscloses example systems including, among other components, software orfirmware executed on hardware, it should be noted that such systems aremerely illustrative and should not be considered as limiting. Inparticular, it is contemplated that any or all of the disclosedhardware, software, and/or firmware components could be embodiedexclusively in hardware, exclusively in software, exclusively infirmware or in some combination of hardware, software, and/or firmware.

What is claimed is:
 1. An interconnect device comprising: a crossbarswitch including a multi-protocol port, and a first port and a secondport; a first protocol adapter coupled to the first port, to decapsulatepackets specific to a first protocol and route decapsulated packets to afirst driver specific to the first protocol; a second protocol adaptercoupled to the second port, to decapsulate packets specific to a secondprotocol different from the first protocol and route decapsulatedpackets to a second driver specific to the second protocol; and a linkcoupled between the multi-protocol port and a second switch, wherein themulti-protocol port is to concurrently transfer data to and receive datafrom both the first and second adapter ports, to interconnect with thesecond switch with packets for both the first protocol and the secondprotocol over the link.
 2. The interconnect device of claim 1, whereinthe crossbar switch comprises an element of a switching fabric ofmultiple switches.
 3. The interconnect device of claim 2, wherein thecrossbar switch further comprises a time management unit to distributeand synchronize time through the switching fabric.
 4. The interconnectdevice of claim 1, wherein the first and second protocols compriseprotocols selected from PCI Express, USB, DisplayPort, and HDMI.
 5. Theinterconnect device of claim 4, wherein the first protocol comprisesDisplayPort and the second protocol comprises PCI Express.
 6. Theinterconnect device of claim 1, wherein the crossbar switch is toencapsulate outgoing protocol-specific packets into transport layerpackets.
 7. The interconnect device of claim 1, wherein the linkcomprises an electrical path.
 8. The interconnect device of claim 1,wherein the link comprises an optical path.
 9. The interconnect deviceof claim 8, wherein the link comprises an optical path and a power path.10. The interconnect device of claim 1, wherein the crossbar switchcomprises multiple multi-protocol ports, at least one port to coupleupstream to a host device, and at least one port to couple downstream ina daisy-chain connection.
 11. An apparatus comprising: a processor; aninterconnect device including: a crossbar switch including amulti-protocol port, and a first port and a second port; a firstprotocol adapter coupled to the first port, to decapsulate packetsspecific to a first protocol and route decapsulated packets to a firstdriver specific to the first protocol; a second protocol adapter coupledto the second port, to decapsulate packets specific to a second protocoldifferent from the first protocol and route decapsulated packets to asecond driver specific to the second protocol; and a link coupledbetween the multi-protocol port and a second switch, wherein themulti-protocol port is to concurrently transfer data to and receive datafrom both the first and second adapter ports, to interconnect with thesecond switch with packets for both the first protocol and the secondprotocol over the link; wherein the processor is to receive data andtransfer data via the interconnect device.
 12. The apparatus of claim11, wherein the crossbar switch comprises an element of a switchingfabric of multiple switches.
 13. The apparatus of claim 12, wherein thecrossbar switch further comprises a time management unit to distributeand synchronize time through the switching fabric.
 14. The apparatus ofclaim 11, wherein the first and second protocols comprise protocolsselected from PCI Express, USB, DisplayPort, and HDMI.
 15. The apparatusof claim 14, wherein the first protocol comprises DisplayPort and thesecond protocol comprises PCI Express.
 16. The apparatus of claim 11,wherein the crossbar switch is to encapsulate outgoing protocol-specificpackets into transport layer packets.
 17. The apparatus of claim 11,wherein the link comprises an electrical path.
 18. The apparatus ofclaim 11, wherein the link comprises an optical path.
 19. The apparatusof claim 18, wherein the link comprises an optical path and a powerpath.
 20. The apparatus of claim 11, wherein the crossbar switchcomprises multiple multi-protocol ports, at least one port to coupleupstream to a host device, and at least one port to couple downstream ina daisy-chain connection.
 21. The apparatus of claim 11, furthercomprising a connector housing to provide a housing for the interconnectdevice.